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ABSTRACT: Current approaches to access control on Web servers do not scale 
to enterprise-wide systems, since they are mostly based on individual users. 
Therefore, we were motivated by the need to meinage and enforce the strong 
access control technology of RBAC in large-scale Web environments. RBAC is 
a successful technology that will be a central component of emerging enterprise 
seciurity infrastruct vires. Cookies can be used to support RBAC on the Web, 
holding users' role information. However, it is insecure to store and transmit 
sensitive information in cookies. Cookies are stored and transmitted in clear 
text, which is readable and easily forged. 

In this paper, we describe an implementation of Role-Based Access Control 
with role hierzurchies on the Web by secure cookies. Since a user's role informa- 
tion is contained in a set of secure cookies and trcinsmitted to the corresponding 
Web servers, these servers can trust the role information in the cookies after 
cookie-verification procedures and use it for role-based access control. In our 
implementation, we used CGI scripts cind PGP (Pretty Good Privacy) to pro- 
vide security services to secure cookies. The approach is transparent to users 
and applicable to existing Web servers and browsers. 

KEYWORDS: Cookie, Role-Based Access Control (RBAC), WWW Security 

1 Introduction 

WWW is commonplace. Increased integration of Web, operating system, and database 
system technologies will lead to continued reliance on Web technology for enterprise com- 
puting. However, current approaches to access control on Web servers axe mostly based on 
individual users; therefore, they do not scale to enterprise-wide systems. 

A successful marriage of the Web and a strong and eflficient access control technology has 
potent iad for considerable impact on and deployment of effective enterprise- wide security in 
large-scale systems. Role-based access control (RBAC) [San98] is a promising technology 
for managing and enforcing security in large-scale enterprise-wide systems, and it wiU be a 
centrgj component of emerging enterprise security infrastructures. We were motivated by 
the need to manage and enforce the strong access control technology of RBAC in large-scale 
Web environments. 

To support RBAC on the Web, we chose a relatively mature technology, cookies - 
widely used on the Web - and have extended it for our purpose. Cookies were invented 
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to maintain continuity and state on the Web [KM97, KM98]. Cookies contain strings of 
text chaicLCters encoding relevant information about the user. Cookies are sent to the user's 
memory via the browser while the user is visiting a cookie-using Web site, and are stored 
on the user's hard disk after the browser is closed. The Web server gets those cookies back 
and retrieves the user's information from the cookies when the user later returns to the 
same Web site or domain. The purpose of a cookie is to acquire information and use it 
in subsequent commimications between the Web server and the browser without asking for 
the same information again. Often a Web server sets a cookie to hold a pointer, such as an 
identification number, as a user-specific primary key of the information database maintaiined 
in the server. Technically, it is not difficult to make a cookie carry relevant information. For 
instance, a merchant Web server could use a cookie containing the user's name and credit 
card number. This is convenient for users, since they do not have to read lengthy nmnbers 
from their cards and key these in for every transaction. However, it is not safe to store 
and transmit this sensitive information in cookies because cookies are insecure. Cookies 
are stored and transmitted in clear text, which is readable and easily forged. Therefore, we 
should render secure cookies to carry and store sensitive data in them. 

We will provide secure cookies with three types of security services: authentication, 
integrity, and confidentiahty. Authentication services verify the owner of the cookies. In- 
tegrity services protect cookies against the threat that the contents of the cookies might 
be changed by imauthorized modification. Finally, confidentiality services protect cook- 
ies against the values of the cookies being revealed to an imauthorized entity. Details for 
these techniques have varying degrees of security and convenience for users and system 



In this paper, we will describe how we implemented KBAC with role hierarchy [FCK95, 
SCFY96] on the Web using the secure cookies. Tb provide security services to secure cookies, 
we used CGI scripts and the PGP (Pretty Good Privacy) package, which are already in 
widespread current use. 

The rest of this paper is organized as follows. First, in Section 2, we describe the 
technologies most relevant to our work, such as RBAC, cookies, and PGP. In Section 3, we 
describe security threats to cookies, and how to design secure cookies to support RBAC on 
the Web. In Section 4, we describe how we actually implemented RBAC on the Web by 
secm*e cookies, using CGI scripts and PGP on an existing Web server. Section 5 gives our 
conclusions. 

2 Related Technologies 

2.1 Role-Based Access Control (RBAC) 

Role-based access control (RBAC) [San98] has rapidly emerged in the 1990s as a promising 
technology for managing and enforcing security in large-scale enterprise-wide systems. The 

^For secure communications on the Web, we may consider using other existing technolo^es, such as, 
SHTTP (Secure HTTP [RS98, SR98]) and SSL (Secure Socket Layer [WS96]). However, these technologies 
cannot solve the stateless problem of HTTP. Furthermore, none of these can prevent end-system threats to 
cookies. 
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basic notion of RB AC is that permissions are associated with roles, and users are assigned 
to appropriate roles. This greatly simplifies security management. 

A role is a semantic construct forming the basis of access control policy. With KBAC, 
system administrators can create roles, grant permissions to those roles, and then assign 
users to the roles on the basis of their specific job responsibilities and policy. Therefore, 
role-permission relationships C£in be predefined, which makes it simple to assign users to the 
predefined roles. Without RJ3AC, it is diflScult to determine what permissions have been 
authorized for what users. 

RJ3AC is a promising alternative to traditional discretionairy and mandatory access con- 
trols, and ensures that only authorized users are given access to certain data or resources. 
It also supports three well-known security poUcies: data abstraction, least-privilege assign- 
ment, and separation of duties. 

2.2 Cookies 

At present, there are many browsers that support cookies, including Netscape, MS Internet 
Explorer, GNNWorks, NetCruiser and OmniWeb. Cookies have been used for many pur- 
poses on the Web, such as selecting display mode (e.g., frames or text only), shopping cart 
selections, and carrying names, passwords, accoimt numbers, or some other bits of identify- 
ing data on the user's machine. Although there are many ways to use cookies on the Web, 
the basic process and the contents of cookies £u-e simileir. The detailed cookie specifications 
are avaUable in [KM97, KM98]. 

Whenever a browser sends an HTTP request for a URX* to a Web server, only those 
cookies relevant to that server will be sent by the browser. If the server finds any cookies 
that are related to the server, those cookies are used during this communication between 
the browser and the server. However, if the server does not find any cookies specified for 
it, either that server does not use cookies in the commimication or the server creates new 
cookies for subsequent conunimication between the browser and the server. 

Web servers may update the contents of their -cookies for any specific circumstance. 
The cookie-issuer is not important for cookie validation. In other words, a server can create 
cookies for other servers in the domain. This is an important aspect of cookies that will be 
used in our implementations described in Section 4. 

2.3 Pretty Good Privacy (PGP) 

PGP (Pretty Good Privacy), a popular software package originally developed by Phil Zim- 
mermaim, is widely used by the Internet commimity to provide cryptographic routines for 
e-mail, file transfer, and file storage applications [Zim95]. A proposed Internet standard 
has been developed [CDFT98], specifying use of PGP. It uses existing cryptographic al- 
gorithms and protocols and nms on multiple platforms. It provides data encryption and 
digitetl signature functions for basic message protection services. 

PGP is based on public-key cryptography. It defines its own public-key pair management 
system and public-key certificates. The PGP key management system is based on the 
relationship between key owners, rather than on a single infrastructure such as X,509. 




Basically, it uses RSA for the convenience of the public-key cryptosystem, message digests 
{MD5, IDEA) for the speed of process, and Diffie-Helhnan for key exchange. The updated 
version supports more cryptographic algorithms. 

Even though the original piurpose of PGP is to protect casual e-mail between Internet 
users, we decided to use the PGP package. The package is aheady widely used and satisfies 
our requirements, in conjunction with Web servers via CGI scripts for our implementation 
to protect cookies. These cookies have role information of the user. 

3 Secure Cookies 

3.1 Security Threats to Cookies 

We distinguish three types of threats to cookies: network security threats^ end-system threats 
and cookie-harvesting threats. Cookies transmitted in clear text on the network are suscep- 
tible to snooping (for subsequent replay) and to modification by network threats. Network 
threats can be foiled by use of the Secure Sockets Layer (SSL) protocol [WS96] which is 
widely deployed in servers and browsers.^ However, SSL can only secure cookies while they 
are on the network. Once the cookie is in the browser's end system it resides on the hard 
disk or memory in clear text. Such cookies can be trivially altered and can be easily copied 
from one computer to another, with or without connivance of the user on whose machine 
the cookie was originally stored. We call this the end-system threat. The ability to alter 
cookies allows users to forge authorization information in cookies and to impersonate other 
users. The ability to copy cookies makes such forgery and impersonation all the easier. 
Additionally, if an attacker collects cookies by impersonating a site that accepts cookies 
firom the users (who believe that they are commun i eating with a legitimate Web server), 
later he can use those harvested cookies for all other sites that accept those cookies. We 
call this the cookie-harvesting threat. These attacks are cdl relatively easy to carry out and 
certainly do not require great hacker expertise. 

3.2 Designing Secure Cookies for RBAC on the Web 

Li this subsection, we describe how to transform regular cookies - which have zero security 
- into seciure cookies, which provide the classic security services against the three types of 
threats to cookies (described in the previous subsection). 

Secure cookies provide three types of secmrity services: authentication^ integrity, and 
confidentiality services. Selection of the kinds and contents of seciu*e cookies depends on 
applications and a given situation. However, at least one authentication cookie and the 
SeaLCookie - which provides the integrity service to the cookies - must be used with other 
cookies to frame basic security services, regardless of appUcations. 

Figure 1 shows a set of secure cookies that we will create and use for RBAC on the 
Web. The Name.Cookie contains the user's name (e.g., Alice), and the Role.Cookie holds 

^In many cases due to export restrictions from USA only weak keys (40 bits) are supported, but SSL 
technology is intrinsically capable of very strong protection against network threats. 
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Figure 1: A Set of Secure Cookies for RBAC on the Web 



the user's role mformation (e.g., Director). The Life_Cookie is used to hold the lifetime 
of the secure-cookie set in its Cookie-Value field and enables the Web server to check the 
integrity of the lifetime of the secure-cookie set. Tb protect these cookies firom possible at- 
tacks, we will use IP_Cookie, Pswd_Cookie, and SeaLCookie. Authentication cookies (i.e., 
IP -Cookie and Pswd_Cookie) verify the owner of the cookies by comparing the authentica- 
tion information in the cookies to those coming fi:om the users. The IP .Cookie holds the 
IP number of the user's machine, and the Pswd_Cookie holds the user's encrypted pass- 
words. This confidentiality service protects the values of the cookies from being revealed 
to unauthorized entity. In ottr implementation, we used the IP -Cookie and Pswd-Cookie 
together to show the feasibility, but only one of those authentication cookies can be used to 
provide the authentication service. The choice of an authentication cookie depends on the 
situation.^ Finally, the SeaLCookie - which has the digital signature of the cookie-issuing 
server on the secure cookie set - supports integrity service, protecting cookies against the 
threat that the contents of the cookies might be changed by unauthorized modification. 

There are basically two cryptographic technologies applicable for secure cookies: public- 
key-based and secret-key-based solutions. In our implementation, we use the public-key- 
based solution for security services provided by a PGP package via CGI scripts. In the next 
section, we will describe secure cookie creation, verification, and use of the role information 
in the Role_Cookie for RBAC with role hierarchies, in tvirn. 

^It is also possible for authentication to be based on use of RADIUS [RRSW97], Kerberos [SNS88, Neu94], 
and similar protocols. Our focus in this work is on techniques that make secure cookies self-sufficient rather 
than pEirtly relying on other security protocols, which is always possible. 
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4 RBAC Implementation by Secure Cookies 

Figure 2 shows a schematic of RBAC on the Web. The role server has tiser-role assignment 
information for the domain. After a successful user authentication, the user receives his or 
her assigned roles in the domain from the role server. Later, when the user requests access 
to a Web server with the assigned roles in the domain, the Web server sillows the user to 
execute transactions based on the user's roles instead of identity. The Web servers may 
have role hierarchies or constraints based on their policies. 

However, how can the Web servers trust the role information presented by users? For 
instance, a malicious user may have unauthorized access to the Web servers by using forged 
role information. Therefore, we must protect the role information from being forged by any 
possible attacks on the Web as well as in the end-systems. 

There can be many possible ways to support the above requirement. In this paper, as one 
possible solution, we will describe how to protect the role information from possible threats 
using secure cookies, and how we implemented RBAC (Role-Based Access Control) with 
role hierarchy on the Web. Figure 3 shows how the secure cookies (including a Role.Cookie) 
for RBAC are created and used on the Web. If a user, let's say AUce, wants to execute 
transactions in the Web servers in an RBAC-compUajit domedn, she first connects to the 
role server in the beginning of the session. After the role server authenticates AUce, it finds 
AUce's expUcitly assigned roles m the URA (User-Role Assignment [SP98, SB97]) database 
and creates a set of secure cookies: Name-Cookie, Life_Cookie, Role.Cookies, IP -Cookie, 
Pswd-Cookie, and SeaLCookie. Then, those secure cookies are sent to and stored in Alice's 
hard drive securely so that Alice does not need to go back to the role server to get her 
assigned roles until the cookies expire. Namely, she can use the roles in her Role.Cookie 
securely in the RBAC-compliant domain as long as the cookies are valid. 

When Alice requests access to a Web server - which has PRA (Permission-Role As- 
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Figure 3: RBAC on the Web by Secure Cookies 



signment [SBC"^97]) information - by typing the server URL in her browser, the browser 
sends the corresponding set of secure cookies to the Web server: Name.Cookie, Life_Cookie, 
Role_Cookies, IP_Cookie, Pswd_Cookie, and Seal_Cookie. The Web server authenticates the 
owner of the cookies by using the IP-Cookie and Pswd.Cookie, comparing the value in the 
cookies with the values coming from the user. The user's passwords are encrypted in the 
Pswd-Cookie using the Web server's pubUc key. The Web server decrypts the value of the 
Pswd-Cookie by using the corresponding key to read the user's passwords. Finally, the 
Web server checks the integrity of the cookies by verifying role server's digital signature in 
the Seal_Cookie using the role server's public key. If all the cookies are valid and verified 
successfully, the Web server trusts the role information in the Role-Cookie and uses it for 
RBAC with a role hierarchy and permission-role assignment information in the Web server. 

4.1 Secure Cookie Creation 

When a user, AUce, connects to the role server (which supports HTTP) of the domain with 
her Web browser, she is prompted by the HTML form to type in her user ID and passwords 
for the domain. We used the POST^ method to send the information to the role server 
and the ACTION field to specify our Cookie-Set CGI program (set-cookie.cgi), to which 
the form data is passed. Figure 4 is a collaborational diagram in UML (Unified ModeUng 

^The GET request is very similar to the POST except that the values of the form variable are sent as 
part of the URL. However, the POST method sends the data after all their request headers have been sent 
to the server. 
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Figure 4: Creating Secure Cookies 



Language [BJR98]) style notation for secure cookie creation. This diagreun shows how we 
create a set of secure cookies for our implementation (refer to the left side of Figure 3). 

The Web server receives the request headers, which include the address to the "set- 
cookie.cgi" program on the server. The server translates the headers into environment 
variables and executes the program. The "set-cookie.cgi" program first retrieves the user 
ID and passwords, and the IP number of the client machine firom the environment variable, 
REMOTE_ADDR. The program authenticates the user by comparing the user ID and pass- 
words with the ones in the authentication database.^ It then assigns the user to roles by 
matching the user ID and the corresponding roles firom the URA (User-Role Assignment) 
database. 

Subsequently, a subroutine for encryption is called to another CGI program (encrypt.cgi), 
which uses PGP to encrypt the passwords by the cookie-verifying Web server's public key. 
These encrypted passwords will be stored in the Pswd_Cookie by the "set-cookie.cgi" pro- 
gram. Then, the "set-cookie.cgi" program creates IP -Cookie, Pswd.Cookie, Name.Cookie, 
Life_Cookie, and Role.Cookie, giving each cookie the corresponding value: IP number of the 
client machine, encrypted passwords, user's n2une, lifetime of the cookie set, and assigned 
roles. 

To support the integrity service of the cookies, the "set-cookie.cgi" program calls another 
CGI program (sign.cgi), which uses PGP to sign on the message digest with the role server's 
private key. The "set-cookie.cgi" then creates the SeaLCookie, which includes the digital 
signatiure of the role server on the message digest of the cookies. 

Finally, the Web server sends the HTTP response header, along with the cookies, back to 
the user's browser, and the cookies are stored in the browser imtil they expire. These secure 
cookies will be verified and used in the Web servers as described in the following subsections. 
Figure 5 is an actual snapshot of a set of seciure cookies from our implementation that are 
stored in the user's maichine after the cookies are generated by the cookie- issuing Web 
server. The contents of the cookies exactly reflect the ones presented in Figure 1. Each 

^If the user already has an authentication cookie in a set of secure cookies, Web servers can use the 
authentication cookie for user authentication instead of authentication databases. 
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tt Netscape HTTP Cookie File 
tt http://tftftf.netscape.coin/newsref/std/cookie_spec. html 
This is a generated file! Do not edit. 
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Figure 5: An Example of Secure Cookies Stored in a User's Machine 



cookie has its corresponding domain, flag, path, secmrity flag, expiration date, nfime, and 
value. The user's name, role, lifetime of the cookie set, IP number, encrypted passwords, 
and the digital signature of the cookie-issuing Web server on the cookies axe stored in the 
corresponding cookies. 



4.2 Secure Cookie Verification 



Figure 6 is a collaborational diagram in UML style notation for secure cookie verification. 
This diagram shows how we verify (corresponding to the right side of Figure 3) the set of 
secure cookies that we generated in the previous subsection for our implementation. When 
Alice connects to a Web server (which accepts the secure cookies) in an RBAC-compUant 
domain, the connection is redirected to the "index.cgi" program. The related secure cookies 
are sent to the Web server and she is prompted by the HTML form to type in her user ID 
and passwords. The "index.cgi" program first uses the HTTP .COOKIE environment vari- 
able to retrieve the secvure cookies (Name_Cookie, Life.Cookie, Role_Cookies, IP -Cookie, 
Pswd-Cookie, and Seal-Cookie) for the Web server. It then checks the validity of all the 
cookies. The two IP addresses, one firom the IP cookie and the other from the environment 
variable, REMOTE.ADDR, are compared. If they are identical, then the host-based au- 
thentication is passed, and a hidden field "status" with the value of "IP-passed" is created 
to indicate that this stage was passed^. However, if the IP numbers are different, the user 

®We used a hidden field to check the completion of the previous stage, which is passed on to the next 
program. This hidden field protects the pages firom being accessed directly, skipping required verification 
steps, by a malicious user. For example, without this hidden field, a malicious user can access the pages 
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Figure 6: Verifying Secure Cookies 



is rejected by the server. 

When the user submits her user ID and passwords to the server, the Web server trains- 
lates the request headers into environment variables, and another CGI program, "password- 
ver.cgi," is executed. We used the POST method to send the information to the Web server 
and the ACTION field to specify the CGI program (password-ver.cgi) to which the form 
data are passed. The first thing the "password-ver.cgi" does is to check the hidden field 
"status" to see if the previous stage was successfully completed. If this is 'TP-passed," 
the program decrypts the value of the Pswd_Cookie (encr5^ted user password) using the 
PGP with the Web server's private key, since it was encrypted with the Web server's public 
key by the role server. The program (password-ver.cgi) then compares the two passwords: 
one from the user and the other decrypted firom the Pswd.Cookie. If they are identical, 
then the user-based authentication is passed, and a hidden field "status" with the value of 
"password-passed" is created to indicate that this stage was passed. However, if the two 
passwords are different, the user has to start again by either retyping the passwords or 
receiving new cookies firom the role server. 

After the password verification is completed, another CGI program, "signature-ver.cgi," 
is activated to check the integrity of the cookies. Like the other programs, it first checks the 
value of "status" passed on from the previous progreun, and it proceeds only if it shows the 
user has been through the password verification stage. If the value is "password-passed," 
then the program verifies the signature in the SeaLCookie with the role server's pubUc key 
using PGP. If the integrity is verified, it means that the cookies have not been altered, and 
a hidden field "status" with the value of "verify-passed" is created to indicate that this 
stage was passed and forwarded to the final program, "rbac.cgi." This program uses the 
role inforrnatipn in the Role-Cookie for role-based access control in the server as described 
in the following subsection. However, if the signature verification is fciiled, the user has to 
start again by receiving new cookies from the role server. 
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4.3 RBAC in the Web Server 

After verifying all the secure cookies, the Web server allows the user, Alice, to execute 
transactions based on her roles, contsdned in the Role_Cookie, instead of her identity. In 
other words, the Web server does not care about the user's identity for authorization pur- 
poses. This resolves the scailabiUty problem of the identity-based access control, which is 
being used mostly in existing Web servers. Furthermore, the Web server can also use a role 
hierarchy, which supports a natural mecois for structuring roles to reflect an organization's 
lines of authority and responsibility. Each Web server may have a role hierstrchy defFerent 
from that in other servers. In our implementation, we used a role hierarcJiy in the Web 
server, depicted in Figure 7. The location of RBAC-compUant Web servers is geographically 
free from that of the role server, since cookies can be issued by one Web server for use by 
others, regardless of their physical location. 

If the "rbac.cgi" program in Figure 6 receives the value, "verify-passed," from the previ- 
ous verification step, it means that the cookies have successfully passed all the verification 
stages, such as IP, passwords, and signature verification. Therefore, the Web server can 
trust the role information in the Role_Cookie, and uses it for role-based access control in 
the server. 

Suppose AUce has the role DIR'^ in her Role.Cookie and she wants to access resources 
for PEl - which require the PEl role or roles senior to the PEl role in the role hierarchy 
- in a Web server. First, she has to prove that the cookies she is presenting are genuine. 
To prove this, she has to go through all the verification steps: IP, passwords, and signature 
verification. She cannot jump ahead or skip any verification stage, as each program requires 
a hidden field, "status," from the previous stage. After the Web server has successfully 

^Multiple roles can be stored in a Role_Cookie. 




completed all the verification steps, the "rbac.cgi" program retrieves the role information, 
Dm, from Alice's Role_Cookie, and shows all the available roles® based on the role hierarchy 
depicted in Figure 7. Since she wants access to the pages that require PEl's privilege, she 
chooses the PEl role to activate it among her available roles. Then she has the permissions 
assigned to the PEl role and the roles junior to PEl, such as El, ED and E. Now, when 
Alice requests access to a particular page in the server, the page checks if her activated role, 
PEl, has permission to access the page. 

The user can use ciny roles among her available roles by activating them. For instance, if 
AUce would activate PLl, then she would be allowed to access the pages, which require the 
PEl role, since PLl is senior to PEl in the role hierarchy. However, if she were to activate 
El, then she would not be allowed to access the pages, since El is jimior to PEl, This 
supports least privileges, since only those permissions required for the tasks are turned on 
by activating the required role. 

How then can the Web server protect the pages from being accessed by imauthorized 
users? Suppose a malicious user. Bob, has the role PBl but wishes to access pages that 
require the PLl role. He could change the value of his Role_Cookie so that it has PLl, or 
roles senior to PLl. He would go through the password verification stages, since he would 
be able to log in as Bob by using his own passwords. However, when his SeaLCookie is being 
verified, there would be a problem, as the signature verification would fail. Therefore, he 
would not be allowed to move beyond this stage. On the other hand, he could try accessing 
the pages directly by typing the URLs. This would not be allowed, since each page checks 
to see if he has activated the required role, PLl, or roles senior to PLl. In other words, 
Bob is not allowed to access the pages, which require roles senior to his, because he cainnot 
activate the senior roles, which are out of his available role range. 

As a result, the Web server allows only users, who have gone through all the verifi- 
cation steps with the secure cookies (Name-Cookie, Life_Cookie, Role_Cookies, IP-Cookie, 
Pswd-Cookie, Seal-Cookie), to access the pages. This access also is possible only if the 
users have the required roles and activate them among their available roles based on the 
role hierarchy. 

5 Conclusions 

In this paper, we have described how we implemented RBAC with role hierarchies on the 
Web using secure cookies. To protect the role information In the cookies, we provided 
security services, such as authentication, confidentiality, and integrity, to the cookies using 
PGP and CGI scripts in the Web servers. The cookie-isstiing Web server creates a set of 
secure cookies including the user's role information, and other Web servers use the role 
information for RBAC with role hierarchies after cookie verification. This access control 
mechanism solves the scalability problem of existing Web servers. The use of secure cookies 
is a transparent process to users and appHcable to existing Web servers and browsers. 

®In this example, all the roles from E to DIR are available to Alice, since she has the senior most role in 
the role hierarchy. 
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